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Abstract —  Control  of  access  to  information  based  upon 
temporal  attributes  can  add  another  dimension  to  access 
control.  To  demonstrate  the  feasibility  of  operating  system- 
level  support  for  temporal  access  controls,  the  Time  Interval 
File  Protection  System  (TIFPS),  a  prototype  of  the  Time  In¬ 
terval  Access  Control  (TIAC)  model,  has  been  implemented 
by  modifying  Linux  extended  attributes  to  include  temporal 
metadata  associated  both  with  files  and  users.  The  Linux 
Security  Module  was  used  to  provide  hooks  for  temporal  ac¬ 
cess  control  logic.  In  addition,  a  set  of  utilities  was  modified 
to  be  TIFPS-aware.  These  tools  permit  users  to  view  and 
manage  the  temporal  attributes  associated  with  their  files 
and  directories.  Functional,  performance,  and  concurrency 
testing  were  conducted.  The  ability  of  TIFPS  to  grant  or 
revoke  access  in  the  future,  as  well  to  limit  access  to  specific 
time  intervals  enhances  traditional  information  control  and 
sharing. 

I.  Introduction 

In  many  situations,  access  to  information  should  not  be 
perpetual.  For  example,  limited  temporal  availability  could 
be  applied  to  items  ranging  from  student  exams  to  medical 
prescriptions.  Exams  should  be  available  to  students  dur¬ 
ing  a  pre-determined  exam  period,  whereas  prescriptions 
might  only  be  valid  for  a  few  weeks  or  months  after  they 
have  been  written.  Current  access  control  systems  do  not 
provide  a  conceptually  simple  and  complete  mechanism  for 
modulating  access  of  subjects  to  files  based  upon  temporal 
attributes:  a  start  time  when  access  is  allowed  and  a  stop 
time  when  access  is  revoked. 

Afinidad  formally  modeled  temporal  access  control  in  the 
Time  Interval  Access  Control  (TIAC)  model  [1],  [2].  To  un¬ 
derstand  the  practical  design  implications  of  such  a  system, 
a  prototype  implementation  of  the  TIAC  model  has  been 
developed  for  the  Linux  operating  system.  The  Time  Inter¬ 
val  File  Protection  System  (TIFPS)  consists  of  a  modified 
Linux  Security  Module  that  implements  the  TIAC  access 
control  logic  [3] .  Extended  attributes  are  used  to  associate 
temporal  metadata  with  files  and  directories.  To  demon¬ 
strate  the  usability  of  TIFPS  at  the  application  level,  a 
number  of  file  management  utilities  were  modified  to  take 
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advantage  of  the  temporal  access  control  mechanism.  Our 
initial  implementation  requires  the  administrator  to  set 
temporal  attributes  on  executables,  viz.  the  login  shell, 
and  objects  prior  to  user  access  to  the  system.  Implementa¬ 
tion  of  temporal  access  control  mechanisms  in  the  operating 
system  offers  several  advantages:  a  consistent  and  coherent 
abstraction  presented  to  all  applications;  an  encapsulated 
mechanism;  and  protection  of  the  mechanism  from  arbi¬ 
trary  modification  by  applications.  The  TIFPS  prototype 
adds  another  layer  of  protection  against  unauthorized  ac¬ 
cess  to  files  and  directories,  and  serves  as  a  starting  point 
for  experimentation  in  temporal  access  control  systems. 

II.  Background 

This  section  briefly  reviews  related  work  in  temporal  ac¬ 
cess  controls  contrasting  it  with  the  TIAC  model.  Possi¬ 
ble  implementations  of  TIAC  are  discussed  and  features  of 
Linux  relevant  to  a  TIAC  implementation  are  presented. 

A.  Time  Interval  Access  Control  (TIAC)  Model 

Authorization  models  using  temporal  constraints  or  tem¬ 
poral  attributes  have  been  proposed  previously.  Bertino  et 
al.  described  a  model  [4],  [5]  that  associated  temporal  con¬ 
straints  with  access  authorizations  and  models  temporal 
dependencies  among  authorizations.  The  notion  of  asso¬ 
ciating  temporal  constraints  with  authorizations  was  ex¬ 
tended  in  an  access  control  model  that  supported  discon¬ 
tinuous  temporal  constraints  on  authorizations  [6].  Role- 
Based  Access  Control  (RBAC)  has  also  been  extended  to 
support  temporal  constraints  to  the  activation  and  deacti¬ 
vation  of  roles  [7].  Alturi  and  Gal  [8],  [9]  proposed  a  model 
somewhat  more  closely  related  to  TIAC:  access  control  con¬ 
straints  are  based  on  temporal  attributes  associated  with 
the  data  as  well  the  time  of  the  data  access  request. 

None  of  the  authorization  models  mentioned  above  sup¬ 
port  policies  based  on  temporal  attributes  associated  with 
both  subjects  (e.g.,  a  process  representing  the  user)  and 
objects  (e.g.,  data).  Seminal  work  [10],  [11],  [12]  has  mod¬ 
eled  authorizations  for  subjects’  to  access  to  objects  using 
an  access  matrix  or  tabular  form.  In  particular,  Graham 
and  Denning  [10]  described  how  the  access  matrix  was  de¬ 
rived  from  the  3-tuple  of  subjects,  objects,  and  a  set  of 
allowed  modes  of  access.  The  TIAC  model  [1],  [2]  extends 
this  approach  by  adding  time  as  a  decision  variable. 

Using  interval  algebra  [13],  the  TIAC  model  associates 
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temporal  attributes  with  subject  and  object  entities  and 
describes  access  authorizations  in  terms  of  access  graphs. 
The  TIAC  formal  semantics  is  unambiguous  and  provides 
the  ability  to  precisely  decide  when  a  subject  with  a  given 
set  of  temporal  attributes  has  permission  to  access  an  ob¬ 
ject,  which  is  also  endowed  with  temporal  attributes.  Since 
the  model  requires  only  three  time  intervals:  those  associ¬ 
ated  with  subject  and  object,  and  the  time  interval  during 
which  access  is  requested,  TI AC-based  access  policies  can 
be  checked  for  consistency  using  decidable  algorithms  [1], 

To  demonstrate  the  feasibility  of  constructing  a  fine¬ 
grained  temporal  access  control  system  based  on  the  TIAC 
model,  a  prototype  was  designed  that  utilized  a  combina¬ 
tion  of  hardware  and  software,  the  Time  Interval  Memory 
Protection  System  (TIMPS)  [14]. 

TIMPS  employs  the  TIAC  logic  to  control  memory  ac¬ 
cess  at  the  page  level. 

The  access  control  mechanism  was  logically  divided  into 
an  initial  authorization  phase,  an  ongoing  access  phase ,  and 
a  termination  phase.  For  the  ongoing  phase,  the  use  of 
hardware  in  combination  with  software  offered  some  perfor¬ 
mance  benefit;  however,  an  implementation  based  entirely 
in  software  is  both  more  flexible  and  practical. 

To  gauge  the  performance  impact  of  TIAC,  we  first  con¬ 
sidered  implementing  TIMPS  entirely  in  software.  It  was 
quickly  realized  that  such  an  implementation  is  impractical 
due  to  the  page-level  granularity  that  would  be  imposed. 
In  particular,  if  temporal  access  controls  are  based  on  pages 
and  the  higher-level  controlled  entities  are  not  page  aligned, 
then  the  access  control  mechanism  would  hinder  system 
functionality. 

The  software  implementation  of  the  TIAC  model  de¬ 
scribed  here  controls  access  at  the  file-level,  where  file  or 
regular  file  refers  to  a  regular  file  in  a  mounted  file  system; 
it  does  not  include  pipes,  sockets,  devices,  etc.  Linux  was 
chosen  as  the  target  system  for  our  TIAC  implementation. 

B.  Linux  File  Management 

The  Linux  kernel  implements  a  Virtual  File  System 
(VFS)  [15]  [16]  that  allows  different  file  systems  to  coexist 
and  interoperate,  and  enables  a  homogeneous  set  of  high- 
level  file  operations. 

To  allow  additional  management  and  control  over  file  ac¬ 
cesses,  Linux  Kernel  Versions  2.6  and  later  implement  Ex¬ 
tended  Attributes  for  most  file  systems.  These  extended 
attributes  take  the  form  of  <  name,  value  >  pairs,  and 
are  associated  and  stored  permanently  with  files.  These 
attributes  provide  a  consistent  means  to  extend  file  sys¬ 
tem  capabilities  while  maintaining  the  independence  of  the 
underlying  file  system  implementation.  In  this  work,  the 
extended  security  attributes  supported  in  the  Linux  2.6.15 
kernel  were  used  to  add  a  single  set  of  temporal  attributes 
to  files  and  directories. 

In  the  TIFPS  prototype,  attributes  are  set  by  the  ad¬ 


ministrator,  i.e.  the  root  user,  and  runtime  logic  prop¬ 
agates  attributes  in  support  of  the  access  control  policy. 
Files  and  directories  lacking  temporal  attributes  are  treated 
as  if  temporal  access  is  permitted  at  all  times.  A  simple 
command-line  utility  facilitates  administrative  control  over 
temporal  attributes  associated  with  files  and  directories. 
The  utility  also  permits  normal  users  to  view  temporal  at¬ 
tributes,  while  additional  options  allow  administrators  to 
modify  those  attributes.  To  provide  user-level  TIFPS  sup¬ 
port,  additional  command-line  utilities  have  been  adapted 
to  be  TIFPS-aware. 

III.  Design  and  Implementation  of  TIFPS 

Starting  with  requirements,  this  section  describes  the  de¬ 
sign  and  implementation  of  the  Time  Interval  File  Protec¬ 
tion  System  (TIFPS)  and  noteworthy  aspects  of  the  im¬ 
plementation.  We  conclude  with  a  short  description  of  a 
number  of  Linux  command  line  utilities  that  have  been 
made  TIFPS-aware. 

A.  Kernel  Support  for  TIFPS 

To  ensure  that  the  TIFPS  implementation  provided  a  co¬ 
herent  set  of  functions,  a  set  of  objectives  was  established. 


Fig.  1.  High-level  flow  logic  for  TIFPS  access  control. 


•  Existing  access  control  policies  will  be  supplemented  by 
temporal  access  controls  such  that  access  is  granted  only  if 
all  policy  checks  succeed. 

•  The  prototype  will  not  apply  temporal  access  controls  to 
objects  that  have  not  been  assigned  temporal  attributes. 

•  For  all  objects  with  temporal  access  attributes,  the  ker¬ 
nel  will  mediate  temporal  access  to  those  objects  based  on 


ISBN  9-9999-9999-9/99/  $20.00  ©2007  IEEE 


310 


those  attributes.  All  forms  of  access  will  be  mediated,  viz. 
read,  write,  and  execute. 

•  For  the  TIFPS  prototype,  only  the  administrator,  i.e. , 
the  super  user,  may  modify  the  temporal  attributes  asso¬ 
ciated  with  objects. 

•  When  the  time  of  access  expires,  access  revocation  should 
take  place  to  at  least  one  second  precision. 

•  For  operations  that  could  result  in  the  creation  of  copies 
of  temporally  controlled  information,  the  destination  files 
must  take  on  the  most  restrictive  temporal  attributes  of 
any  files  read  by  the  copying  process. 

•  The  administrator  will  be  able  to  set  time-of-allowed  ac¬ 
cess  for  subjects,  i.e.  user  accounts,  and  objects,  i.e.  regu¬ 
lar  files  and  directories. 

A  high-level  view  of  the  logic  for  TIFPS  access  control 
decisions  is  illustrated  in  Figure  1.  When  a  user  logs  into  a 
TIFPS-enabled  system,  the  login  shell  inherits  the  tempo¬ 
ral  attributes  Tstart  and  Tend  specified  in  advance  by  the 
administrator.  Fstart  and  Fend  define  the  time  interval  of 
allowed  access  for  a  particular  object.  For  pre-existing  files, 
the  system  administrator  specifies  in  advance  the  temporal 
attributes  Fstart  and  Fend  for  those  objects  that  require 
temporal  access  control. 

Invocation  of  executables  via  the  shell  results  in  the 
process  inheriting  the  temporal  attributes  of  its  parent. 
When  a  process  (subject)  attempts  to  access  a  file  and  af¬ 
ter  the  standard  Linux  read,  write,  execute  permissions  are 
checked,  the  system  checks  the  current  time  Tcurr  against 
the  temporal  attributes  Tstart  and  Tend .  If  current  time  is 
within  the  time  interval  specified  by  Tstart  and  Tend,  then 
the  objects’s  time  attributes  are  checked.  If  the  current 
time  falls  within  the  time  interval,  Fstart  and  Fend ,  speci¬ 
fied  for  the  object,  then  access  is  granted.  Thus,  access  is 
granted  in  TIFPS  only  if  the  following  is  true: 


T, 


<  t 


<r"  T _ i  find 


To  prevent  unauthorized  extension  of  access  to  informa¬ 
tion  by  copying,  when  read  access  to  an  object  is  requested 
in  TIFPS,  the  process’s  temporal  attributes  are  updated 
to  take  on  the  intersection  of  the  temporal  attributes  of 
the  object  being  read  and  the  process’s  current  temporal 
attributes.  This  is  illustrated  in  Figure  2.  After  a  program 
reads  objects  with  temporal  attributes  Fi_start,  Fi_end  and 
F2  —start  5  F2 — e. ft, (I,  ■  any  write  operation  to  new  or  existing  ob 
jects  will  transfer  the  most  restrictive  time  attributes  asso¬ 
ciated  with  any  of  the  objects  read  to  the  objects  written. 

To  support  temporal  access  control  on  subjects,  as  de¬ 
fined  by  the  TIAC  model  [1]  [2],  temporal  attributes  for  the 
first  process  (subject)  of  a  user  session  are  initialized  by 
copying  the  rights  on  the  login  directory  to  the  subject. 
The  administrator  is  authorized  to  grant  and  revoke  time- 
based  access  to  users  by  applying  temporal  attributes  to 
home  directories.  When  the  user  logs  in,  the  process  exe¬ 
cuting  on  his  behalf  inherits  the  attributes  of  the  directory. 


By  ensuring  that  each  child  process  inherits  the  tempo¬ 
ral  attributes  of  its  parent,  temporal  access  control  can  be 
imposed  on  all  subjects  created  during  a  user’s  session. 


Subject  S 
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■  i  > 
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Fig.  2.  TIFPS  read  and  write  policy. 


A.l  Implementation  considerations 

In  Linux,  time  is  represented  by  a  4-byte  signed  integer, 
which  specifies  the  number  of  seconds  since  the  start  of  the 
Unix  epoch.  A  negative  integer  represents  the  number  of 
seconds  before  the  Unix  epoch.  Since,  for  TIFPS,  times 
prior  to  1970  are  irrelevant,  the  TIFPS  extended  attribute 
has  a  value  range  of  0x00000000  to  0x7FFFFFFF,  i.e.,  from 
1  January  1970  at  00:00:00  UTC  to  the  year  2038,  which 
we  call  TUnix0  and  TUnixINF,  respectively. 

Extended  attributes  are  used  for  persistent  storage 
of  the  TIFPS  temporal  attributes  for  objects  and  are 
stored  as  strings.  The  string  representation  of  the  name 
of  the  extended  attribute  for  TIFPS  is  “security.tifps” . 
The  value  of  the  extended  attribute  has  the  format 
“:0x00000000:0x7FFFFFFF\0”,  where  the  first  hexadeci¬ 
mal  number  represents  Fstart  and  the  second  hexadecimal 
number  represents  Fend .  Storing  temporal  attributes  in 
this  format  simplifies  string  parsing  during  access  control 
operations. 

“Ext3”,  a  popular  journaling  file  system  that  is  installed 
by  default  and  supports  extended  attributes  [17]  was  chosen 
for  the  TIFPS  prototype.  However,  to  the  extent  possible, 
the  prototype  was  kept  sufficiently  generic  to  support  other 
extended  attribute  file  systems,  such  as  “ext2”  and  “xfs”. 

To  avoid  implementing  temporal  access  control  either  in¬ 
side  the  kernel  or  with  custom  security  hooks,  an  existing 
framework  was  needed.  The  Fedora  Core  5  (FC5)  distribu¬ 
tion  includes  the  Linux  Security  Module  (LSM) ,  a  modular 
security  framework  that  provides  kernel-callable  security 
hooks  [18].  These  generic  security  hooks  can  be  used  to 
implement  different  security  policies. 

Two  other  Linux  security  frameworks  were  considered. 
Rule  Set  Based  Access  Control  (RSBAC)  [19],  unlike  LSM, 
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does  not  require  that  the  security  hook  functions  be  ex¬ 
ported  to  user-space  programs.  Another  is  Grsecurity  [20]. 
It  is  a  multi-layered,  detection,  prevention,  and  contain¬ 
ment  framework  for  Linux  security.  Despite  the  enhanced 
security  features  of  RSBAC  and  Grsecurity,  LSM  was  cho¬ 
sen  for  the  TIFPS  implementation  because  of  its  stability 
and  broad  acceptance.  Since  TIFPS  addresses  only  files 
and  directories,  a  subset  of  the  LSM  security  hooks  was 
sufficient. 

In  addition  to  LSM,  VMware  Server  1.0.0  was  used  both 
to  host  a  dedicated  Subversion  1.3. 0-4. 2  [21]  versioning 
server,  and  for  target  kernel  development  and  testing.  Fe¬ 
dora  Core  5  -  Kernel  2.6.15  [22],  the  target  operating  sys¬ 
tem,  was  reduced  to  the  minimum  number  of  kernel  mod¬ 
ules  and  drivers  required  to  run  the  system.  The  kernel 
configuration  file  is  available  in  the  prototype  source  [3]. 
Source  Insight  3.5  [23]  and  Emacs  21.4-14  supported  ker¬ 
nel  source  code  inspection  and  modification. 

To  use  LSM,  the  —init()  and  __ exit( )  functions  had  to 
be  defined.  The  security-operations  structure  was  used  to 
implement  custom  security  functions  for  each  of  the  secu¬ 
rity  hooks  [3].  Since  default  security  hooks  have  no  effect, 
it  was  sufficient  to  implement  only  the  security  hook  func¬ 
tions  necessary  to  achieve  the  desired  system  behavior. 

In  the  Linux  kernel,  taskstruct  contains  metadata  on 
processes  and  inodes  contain  metadata  on  files,  directories, 
and  other  file  system  objects.  The  Linux  Security  Mod¬ 
ule  predefines  in  each  of  these  data  structures  a  security 
object  pointer  to  a  security  structure  that  is  custom  de¬ 
fined  for  the  specific  LSM  implementation.  In  the  TIFPS 
LSM  implementation,  the  security  structure  defined  for 
processes  is  named  tifps -task-security struct  and  has  the 
following  fields:  a  4-byte  back  pointer  to  the  taskstruct, 
a  semaphore  data  structure  used  for  synchronization,  and 
two  signed  integers  representing  Tstart  and  Tend  for  al¬ 
lowed  access  by  the  process.  The  inode  security  structure 
is  named  tifps-inodesecuritystruct  and  has  the  following 
fields:  4- byte  back  pointer  to  the  inode  struct,  a  semaphore 
data  structure,  and  two  signed  integers  representing  Fstart 
and  Fend  for  allowed  access  to  the  object  represented  by 
the  inode  structure  [3]. 

A. 2  Implementation  details 

On  system  initialization,  with  TIFPS  LSM  loaded,  the 
kernel  allocates  a  tifps-task-securitystruct  for  the  cur¬ 
rent  running  process,  initializes  the  semaphore  struct, 
and  sets  the  TIFPS  start  and  end  times  to  Tjjnixo  and 
TunixiNF ,  respectively.  Subsequent  tasks  are  also  allocated 
a  tifps-tasksecuritystruct.  Figure  3  depicts  the  low-level 
time  policy  enforcement  logic. 

Preliminary  analysis  shows  that  the  restrictive  policy 
with  respect  to  time  intervals  introduces  a  problem.  Con¬ 
sider  an  example:  Assume  that  a  user  reads  a  file  that 
expires  5  minutes  after  the  user  has  logged  into  the  sys- 


Fig.  3.  Flow  chart  of  low-level  TIFPS  enforcement  logic. 


tern.  After  reading  the  file,  then,  due  to  the  inheritance 
of  temporal  attributes,  the  process’s  time-of-allowed  access 
also  expires  in  5  minutes.  So,  after  5  minutes,  the  task  will 
not  be  allowed  to  access  any  other  files. 

One  modification  of  the  policy  that  was  considered  but 
not  implemented  is  described  here.  Since  the  intent  is 
to  preserve  the  temporal  attributes  on  information,  the 
tifps-tasksecuritystruct  could  be  implemented  to  “keep 
track  of”  (as  opposed  to  inherit)  the  most  restrictive  tem¬ 
poral  attributes  based  on  the  intersection  of  previously  ac¬ 
cessed  objects’  attributes.  Only  during  an  attempt  to  write 
would  the  system  enforce  access  control  and  transfer  the 
temporal  attribute  with  the  most  restrictive  time  interval 
to  the  objects  being  written.  This  work-around  was  not  im¬ 
plemented  because  the  file  read  operation  implies  a  write 
operation  to  the  kernel  stack,  and  thus  the  same  problem 
would  persist. 

For  the  purpose  of  the  current  prototype,  the  fork-and- 
exec  paradigm  of  Unix-based  operating  systems  obviates 
the  problem.  When  a  user  logs  into  a  Unix  system,  that 
user’s  login  shell  runs  as  a  process.  Execution  of  a  program 
by  the  shell  starts  with  a  fork()  invocation  which  clones  the 
parent,  thus  creating  the  child  process.  An  exec()  within 
the  child  process  replaces  the  executable  of  the  child  so 
that  the  intended  new  process  runs.  Hence,  it  is  the  child 
process  that  actually  executes  the  command,  reading  from, 
and  writing  to  files.  Thus  the  temporal  attributes  of  the 
parent  login  shell  are  not  affected. 

Also,  an  implementation-specific  choice  was  also  made 
with  respect  to  attribute  inheritance.  When  creating  a  new 
process  via  a  fork,  which  clones  the  “parent”  process,  the 
security-task-alloc()  security  hook  function  is  called  from 
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the  copy -process  ()  kernel  function.  Since  the  attributes 
copied  to  the  child  are  those  that  the  parent  had  when 
the  parent  was  created,  this  meant  that  the  forked  “child” 
inherited  the  temporal  attributes  of  its  “grandparent” .  To 
ensure  that  “child”  processes  inherited  the  temporal  at¬ 
tributes  of  their  “parents”  at  the  time  of  child  process  cre¬ 
ation,  the  parent  attributes  are  used  to  determine  the  child 
process’s  temporal  attributes. 

To  prevent  increasingly  restrictive  access  as  directo¬ 
ries  dynamically  inherit  temporal  attributes,  the  current 
TIFPS  prototype  sets  the  temporal  attributes  of  directories 
upon  their  creation  or  through  explicit  administrative  mod¬ 
ification  operations  and  does  not  dynamically  update  them. 
This  prevents  the  most  restrictive  temporal  attributes  of 
any  user  accessing  it  to  be  applied  to  a  shared  directory 
such  as  /tmp. 

The  TIFPS  policy  and  permission  check  logic  were  imple¬ 
mented  in  the  tifps-enforcer()  function  in  the  helper  func¬ 
tions  section  of  the  tifpsJiooks.c  source  code  file.  The  file 
is  divided  into  two  sections,  one  implementing  the  secu¬ 
rity  hook  functions  called  by  the  kernel  as  part  of  LSM, 
and  another  implementing  all  the  helper  functions  that  the 
security  hook  functions  call  to  provide  temporal  access  con¬ 
trol. 

Although  TIFPS  was  designed  as  a  loadable  module  for 
the  Linux  Kernel,  the  kernel  configuration  utilities  were 
modified  to  compile  TIFPS  as  either  a  loadable  module  or 
as  an  in  situ  kernel  module.  Compatibility  with  other  secu¬ 
rity  modules  such  as  NSA’s  SELinux  [24]  or  BSD’s  Secure 
Level  LSM  has  not  been  considered  or  tested. 

B.  TIFPS-Aware  Command-Line  Tools 

To  provide  an  interface  to  the  temporal  attributes  asso¬ 
ciated  with  files  and  directories,  a  new  tool  modtime ,  was 
developed  to  meet  the  following  objectives: 

•  Relative  time  will  be  with  respect  to  current  time,  Tcurr. 
(Note  that  internally  the  system  enforces  its  temporal  pol¬ 
icy  based  upon  absolute  time,  e.g.,  on  November  5,  2007 
at  1700  hours  revoke  access  to  parliament.txt) 

•  Temporal  attributes  will  be  set  by  specifying  them  in 
either  absolute  time  or  relative  time. 

•  The  administrative  interface  will  be  easy  to  use;  it  will 
not  require  complicated  time  calculations  by  the  adminis¬ 
trator. 

•  The  tool  will  be  able  to  take  multiple  arguments  to 
change  or  display  the  temporal  attributes  of  multiple  files 
and  directories  at  once. 

•  Usage  instructions  will  be  made  readily  available. 

•  The  tool  will  display  useful  error  messages  to  interactive 
users. 

•  The  tool  will  allow  the  temporal  attributes  of  files  and 
directories  to  be  easily  viewed. 

Fedora  Core  5  as  well  as  other  Linux  operating  systems 
running  Linux  2.6  and  up  include  a  set  of  user-space  pro¬ 


grams  for  setting  and  getting  extended  attributes:  set- 
fattr()  and  getfattr(),  respectively.  Setfattr  can  only  be 
run  by  the  administrator  account,  whereas  getfattr  can  be 
run  by  any  user.  The  modtime  command  was  designed  as 
a  wrapper  program  that  encompassed  these.  The  modtime 
tool  presents  standard  Linux  command  line  tool  syntax  and 
semantics.  A  man  page  describing  its  usage  was  written 
[3], 

The  following  existing  command-line  functions  were 
modified  to  be  TIFPS  aware:  mkdir ,  rmdir,  touch ,  chmod, 
Is,  stat,  file,  find,  rm.  Neither  mv  nor  In  required  modi¬ 
fication  to  become  TIFPS-aware,  and  testing  of  these  two 
utilities  showed  that  they  were  constrained  by  the  under¬ 
lying  temporal  controls.  Man  pages  for  the  TIFPS-aware 
utilities  were  modified  to  reflect  their  new  capabilities. 

IV.  Testing  and  Analysis 

Test  plans  for  validating  TIFPS  for  correct  functional¬ 
ity,  measuring  its  performance  overhead,  and  gauging  its 
robustness  in  multi-user  situations  were  developed. 

A.  Functional  Tests 

Functional  testing  was  conducted  to  ensure  that  the  ac¬ 
cess  control  mechanism  of  TIFPS  LSM  enforced  the  poli¬ 
cies  as  expected.  Both  static  and  dynamic  testing  were 
performed.  The  static  tests  included  experiments  to  ob¬ 
serve: 

•  Enforcement  of  temporal  policies  for  reading,  writing, 
and  executing  files  and  directories,  where  “execution”  has 
the  standard  Linux  semantics, 

•  Inheritance  of  temporal  attributes  in  file  and  directory 
creation  operations  and  in  file-copy  operations, 

•  Possible  corrupted  file  format  information  due  to  incom¬ 
plete  writes  resulting  from  access  revocation.  (Note  that 
directory  writes  are  not  a  problem,  as  these  are  atomic  with 
respect  to  the  access  checks.) 

The  static  tests  for  explicit  file  and  directory  creation 
resulted  in  expected  temporal  attribute  inheritance  behav¬ 
ior. 

A  set  of  copy  tests  was  devised  to  ensure  that  information 
copied  from  one  object  to  another  would  have  the  most 
restrictive  combination  of  attributes  of  the  pair.  Figure  4 
illustrates  three  scenarios  and  the  expected  inherited  time 
interval  for  the  created  file  is  shown.  For  each  of  the  three 
scenarios,  three  ways  to  copy  files  in  Linux  were  tested:  the 
cp  command,  redirection,  and  pipes.  The  tests  using  pipes 
had  unexpected  results  and  will  be  discussed  in  IV-A.l. 

Tests  were  created  to  examine  the  behavior  of  the  system 
when  access  to  a  file  is  revoked  during  a  write  operation. 
The  results  showed  that  file  corruption  could  occur  if  access 
is  revoked  while  an  application  is  writing  state  information 
to  a  file. 

Dynamic  attribute  modification  tests  were  designed  to 
observe  the  behavior  of  the  system  when  temporal  at- 
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Fig.  4.  File  copy  scenarios. 


tributes  are  changed  by  an  administrator  during  a  user 
session.  Two  sets  of  scripts  were  developed:  one  to  ex¬ 
amine  the  effect  of  subject  attribute  modification  and  the 
other  to  determine  the  impact  of  object  attribute  modi¬ 
fication.  System  behavior  from  the  subject  (i.e. ,  user)’s 
perspective  was  recorded  before  and  after  the  change  by 
the  administrator. 

As  expected,  dynamic  modification  of  the  subject’s  tem¬ 
poral  attributes  did  not  affect  the  subject’s  continued  ac¬ 
cess  to  files  and  directories;  the  subject  inherits  temporal 
attributes  at  the  time  of  login,  and  modification  of  subject 
attributes  does  not  take  effect  until  the  next  login.  In  con¬ 
trast,  dynamic  modification  of  object  attributes  is  effective 
immediately  and  results  in  successful  revocation  of  access 
upon  expiration  of  its  allowed  temporal  interval. 

A.l  Analysis 

Two  unresolved  problems  were  encountered  during  static 
testing.  In  addition,  access  revocation  during  file  write 
presented  a  problem. 

To  ensure  that  the  system  consistently  enforced  the  in¬ 
heritance  policy  for  copied  information,  multiple  ways  of 
copying  files  in  a  Linux  system  were  tested.  The  system 
behaved  as  expected  except  when  pipes  were  used  to  copy 
files.  In  this  case  tee  read  from  standard  input  and  sent  the 
bytes  read  to  two  streams:  standard  output  and  a  specified 
destination  file.  Since  tee  reads  from  the  pipe  and,  in  this 
implmentation,  the  pipe  does  not  have  temporal  attributes 
(see  II- A),  the  sequence  of  commands  illustrated  in  Figure 
5  successfully  copies  the  contents  of  source.txt  into  desti¬ 
nation.  txt  without  preserving  the  temporal  attributes  of 
source.txt. 

In  Linux,  inode  data  structures  are  associated  with  pipes. 
Thus,  they  can  be  assigned  temporal  attributes.  This  form 
of  copying  can  be  separated  into  the  following  individual 


Source  txt 


cat  source.txt  I  tee  destination.txt 


Fig.  5.  Use  of  fee  to  copy  files. 


operations,  where  the  parenthesized  actions  indicate  antic¬ 
ipated  TIFPS  attribute  inheritance: 

1.  cat  reads  from  source.txt  ( cat  inherits  attributes  from 
source.txt) 

2.  cat  writes  to  the  pipe  (pipe  inherits  attributes  from  cat) 

3.  tee  reads  from  the  pipe  (tee  inherits  attributes  from 
pipe) 

4.  tee  writes  to  destination.txt  (destination.txt  inherits  at¬ 
tributes  from  tee) 

Within  our  test  environment,  we  determined  that  the  se¬ 
quence  does  not  necessarily  occur  in  the  order  given  above. 
For  example,  on  some  occasions,  the  kernel  scheduler  was 
observed  to  schedule  step  3  first,  and  the  tee  process  will 
block  until  the  cat  process  writes  data  to  the  pipe.  Since 
the  LSM  security  hook  is  called  when  the  tee  process  re¬ 
quests  read  permission  to  the  pipe  and  not  after  it  wakes 
from  blocking,  the  temporal  attributes  of  the  original  file 
will  not  be  correctly  inherited.  A  solution  to  this  problem 
will  require  further  investigation. 

The  second  problem  was  encountered  when  using  the 
tab-completion  feature  of  the  bash  shell.  This  feature  al¬ 
lows  a  user  to  list  all  executables  available  in  his/her  path 
and  when  used  by  the  login  bash  shell,  all  the  executables 
in  a  user’s  path  are  read.  Consequently  the  shell  inherits 
the  most  restrictive  temporal  attributes  of  all  the  executa¬ 
bles.  Additional  examination  of  attribute  inheritance  by 
executables  is  needed  to  solve  this  problem  and  is  relegated 
to  future  work. 

Finally,  the  TIFPS  LSM  does  not  provide  transactional 
support  for  file  writes.  Hence,  if  file  state  information  has 
not  been  written  prior  to  access  expiration,  the  file’s  state 
could  be  inconsistent.  Again,  further  investigation  is  re¬ 
quired  to  determine  a  solution.  One  solution  is  to  support 
file  system  recovery  in  the  kernel. 

B.  Performance  Tests 

Performance  testing  measured  the  additional  overhead 
incurred  by  TIFPS  LSM  temporal  access  checks  compared 
those  for  an  unmodified  kernel.  The  added  overhead  for 
TIFPS  access  control  is  approximately  5%  for  read  oper¬ 
ations,  20%  for  write  operations,  and  9%  for  copy  opera¬ 
tions. 

To  perform  the  tests,  a  set  of  scripts  was  created  to  time 


ISBN  9-9999-9999-9/99/  $20.00  ©2007  IEEE 


314 


Read 
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6.42 

6.71 
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4.65 

4.59 

4.72 

4.65 

32.28 

31.91 

32.59 

32.20 

7.09 

7.09 

7.25 

7.40 

Difference 

5.44% 

4.55% 

5.51% 

5.68% 

20.6% 

20.1% 

18.16% 

19.06% 

9.13% 

10.44% 

8.05% 

7.98% 

TABLE  I 

TIFPS  Performance  Test  Summary  (units  are  in  seconds) 


the  reading,  writing,  and  copying  of  files  on  an  unmodified 
2.6.15  kernel  and  the  same  kernel  loaded  with  the  TIFPS 
LSM.  The  two  kernels  were  guest  operating  systems  on 
a  machine  running  virtualized  VMware  server  images  of 
Fedora  Core  5.  The  hardware  running  the  VMware  image 
has  an  Intel  Pentium  4  processor  running  at  3.00  GHz.  The 
RAM  allocated  for  the  image  is  256M. 

Two  additional  factors  were  considered:  the  intrinsic 
overhead  associated  with  TIFPS-enabled  entities;  and  per¬ 
formance  variations  between  repeated  actions  on  the  same 
file  and  similar  actions  on  different  files.  It  was  hypothe¬ 
sized  that  differences  in  data  structure  allocation  and  ini¬ 
tialization  might  affect  performance. 

The  results  in  Table  I  suggest  that,  contrary  to  hypoth¬ 
esis,  the  presence  of  TIFPS  attributes  did  not  significantly 
affect  the  performance.  The  reason  for  this  result  could  be 
that  most  of  the  performance  overhead  of  TIFPS  occurs 
in  the  setup  of  the  function  calls  to  the  TIFPS  security 
hook  implementations.  In  the  TIFPS  security  hook  imple¬ 
mentations,  access  control  logic  is  skipped  in  the  absence  of 
TIFPS  attributes.  It  appears  that  skipping  sections  of  code 
within  a  security  hook  function  call  did  not  significantly 
reduce  performance  overhead.  Further  experimentation  is 
needed  to  localize  the  cause  of  performance  overhead  in 
TIFPS. 

C.  Concurrency  Tests 

Concurrency  tests  were  performed  to  gauge  the  robust¬ 
ness  of  the  TIFPS  LSM  in  situations  where  multiple  sub¬ 
jects  with  different  temporal  attributes  request  access  to 
the  same  objects.  Three  user  accounts  were  created,  each 
with  different  temporal  attributes.  Four  tests  were  per¬ 
formed. 

1.  When  three  subjects  acting  on  behalf  of  their  respective 
users  attempted  to  continuously  read  the  same  file,  it  was 
found  that  the  revocation  time  for  read  access  for  each 
subject  corresponded  to  the  time  that  the  corresponding 
user’s  time  attributes  expired. 

2.  Three  subjects  attempted  to  continuously  write  to  the 
same  text  file.  When  a  subject’s  write  access  was  revoked, 
the  revocation  time  was  recorded.  In  this  case,  the  file  cor¬ 
rectly  inherited  the  TIFPS  permissions  of  the  user  whose 
temporal  attributes  are  the  most  restrictive.  At  file  expira¬ 
tion,  the  write  access  was  properly  revoked  for  all  subjects. 


3.  When  copying  files  to  their  home  directories,  each  of  the 
subjects’  copies  of  the  file  inherited  the  temporal  attributes 
associated  with  the  individual  user. 

4.  When  subjects  attempt  to  concurrently  copy  private 
files  into  a  shared  directory,  it  was  found  that  each  user’s 
respective  temporal  attributes  were  preserved  as  expected. 
The  shared  directory  retained  its  original  temporal  at¬ 
tributes  as  expected. 

V.  Discussion  and  Future  Work 

The  benefits  of  TIFPS  include  kernel-level  protection  of 
the  mechanism  as  well  as  consistent  policy  enforcement 
across  all  applications.  TIFPS  enforces  proper  inheritance 
of  temporal  attributes  by  subjects  and  objects  for  copy  op¬ 
erations.  This  feature  results  in  a  tension  between  correct 
security  behavior  and  the  availability  of  system  services. 

To  enforce  proper  inheritance  in  a  temporal  access  con¬ 
trol  system,  a  policy  similar  to  the  High  Watermark  [12] 
should  be  implemented:  a  subject’s  level  of  access  becomes 
increasingly  restrictive  as  the  subject  accesses  various  ob¬ 
jects.  As  a  consequence,  enforcement  of  this  policy  may 
result  in  the  association  of  increasingly  restrictive  tempo¬ 
ral  attributes  with  a  subject  during  the  course  of  a  session. 

For  a  typical  Linux  shell,  this  problem  is  mitigated  by 
the  fork-and-exec  paradigm.  Since  the  child  process  incurs 
the  increasing  restrictions  as  various  objects  are  accessed, 
the  parent  is  unaffected.  A  new  child  process  will  inherit 
the  original  less  restrictive  attributes  of  the  parent  shell. 
However,  the  fork-and-exec  paradigm  introduces  additional 
issues.  For  example,  inheritance  of  temporal  attributes  was 
not  consistently  enforced  in  the  copy  operation  performed 
using  pipes  to  communicate  information  between  sibling 
processes  within  the  system.  Therefore,  future  implemen¬ 
tations  should  explicitly  address  the  intended  semantics  of 
the  file  system  to  ensure  that  object  and  subject  temporal 
attributes  are  preserved. 

Our  future  work  on  temporal  access  controls  includes 
enhancements  to  both  the  TIAC  model  and  to  the  TIFPS 
implementation. 

TIAC: 

•  Explore  the  implementation  of  TIAC  in  a  distributed  en¬ 
vironment.  This  must  include  consideration  of  a  reliable 
global  clock. 

•  Extend  the  TIAC  model  to  support  a  temporal  attribute 
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inheritance  policy  that  can  be  formally  checked  for  consis¬ 
tency  and  reasonable  semantics. 

TIFPS: 

•  Examine  the  Linux  fork-and-exec  functionality  to  ensure 
proper  policy  enforcement  when  attributes  are  inherited  by 
new  processes.  Related  to  this  topic  is  the  issue  raised  by 
the  case  of  bash  auto-completion  for  executables. 

•  Support  times  beyond  the  year  2038. 

•  Modify  the  implementation  to  include  other  file  systems 
that  support  extended  attributes,  in  addition  to  “ext3”. 

•  Investigate  write  operations  to  ensure  consistent  file  state 
upon  temporal  attribute  expiration. 

•  A  new  form  of  temporal  attribute  could  be  created  for 
TIFPS  that  could  be  used  to  modulate  access  periodically. 
For  example,  access  to  certain  files  might  be  permitted  only 
between  8  AM  and  5  PM. 

•  Support  a  higher  degree  of  granularity  for  temporal  at¬ 
tributes.  For  example  read,  write,  and  execute  operations 
could  each  have  separate  temporal  attributes. 

•  Consideration  to  the  semantics  of  write  ()  will  be  required 
since  some  file  systems,  e.g.  AFS  [25],  use  delayed  writes 
and  access  could  expire  prior  to  a  close(),  which  would  force 
another  write. 

At  the  application  level,  the  modtime  tool  could  be  ex¬ 
tended  to  support  recursive  directory  descent.  In  addition, 
further  investigation  of  tools  and  APIs  for  use  in  TIAC- 
enabled  systems  will  enhance  utilization  of  temporal  access 
control  systems. 

In  summary,  temporal  access  control  systems  can  aug¬ 
ment  traditional  access  control  mechanisms  to  support 
dynamic  security  services  by  changing  access  permissions 
based  upon  time.  The  capability  of  such  a  system  to  grant 
or  revoke  access  in  the  future,  as  well  to  limit  access  to 
a  specific  time  interval  can  provide  another  dimension  for 
information  control  and  sharing  not  available  in  traditional 
access  control  systems.  The  Linux-based  TIFPS  prototype 
implementation  presented  here  can  be  used  as  a  starting 
point  for  future  temporal  access  control  systems. 
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